Skip to content

Fuzzer: Log exported globals#8466

Open
kripken wants to merge 35 commits intoWebAssembly:mainfrom
kripken:export.moar
Open

Fuzzer: Log exported globals#8466
kripken wants to merge 35 commits intoWebAssembly:mainfrom
kripken:export.moar

Conversation

@kripken
Copy link
Member

@kripken kripken commented Mar 13, 2026

We already exported globals in the fuzzer, but did not do anything with
them. This logs out their values, at the same time that we log out the
values returned from calling exported functions (and using the same
reordering etc.).

@kripken kripken requested a review from tlively March 13, 2026 23:15
@kripken
Copy link
Member Author

kripken commented Mar 13, 2026

Looks like this messes with the auto-update script for the lit test... hmm. Otherwise though this should be ready.

Comment on lines +575 to +578
// Log it at the right time later using a lambda. Note that we can't just
// capture |value| for the lambda, as the loop modifies it.
(() => {
var global = value;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not surprised to be surprised once again by JS semantics. Even the var global = value is not enough to avoid the need for this outer lambda?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't enough, correct. For loops etc. don't create scopes in JS like functions do.

try {
actualValue = global.value;
} catch (e) {
if (e.message.startsWith('get WebAssembly.Global.value')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Can we check the type of the error rather than the message? Error messages are not standardized and may differ between implementations.

  2. Maybe we should print something else to distinguish this case from an exported global actually containing null.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I think it's just a generic RuntimeError, so the text is really all we have to go on...
  2. Hmm, but we'd need to print some value in other fuzzer places too. I don't think this is ambiguous - this happens only for the illegal types. So if the type is v128, we know 'null' means "i can't print this" etc.

Comment on lines +506 to +508
// Log the global's value. (We use "calling" here to match the output
// for calls, which simplifies the fuzzer.)
std::cout << "[fuzz-exec] calling " << exp->name << "\n";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove "calling" everywhere as a follow-up?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea for what to replace it with? We need something to differentiate it from other things. I don't have a good idea myself...

@kripken
Copy link
Member Author

kripken commented Mar 16, 2026

I worked around the auto-updater test issue with a tiny manual test. We really don't need any more here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants